1. Field of the Invention
The present invention relates to the simulation of a physical system such as an automobile, and more particularly to a software-based simulation system.
2. Description of Related Art
In the early 20th century, an automobile was made up of an engine as a power source, and mechanical parts including a brake, an accelerator, a steering wheel, a transmission, and a suspension, with little use of electrical mechanisms except for an ignition plug for the engine and headlights.
However, around the 1970s, there arose the need to control the engine efficiently in preparation for air pollutions, oil crisis, and the like. Thus, an engine control unit (ECU) started to be used for engine control. In general, the ECU includes an input interface used, for example, for A/D conversion of an input signal from a sensor, a logical operation unit (microcomputer) for processing a digital input signal according to predetermined logic, and an output interface for converting the processing result into an actuator operating signal.
A significant proportion of a recent automobile is now occupied not only by mechanical parts but also by electronic components and software, which range from control systems for the engine and the transmission, an anti-lock braking system (ABS), electronic stability control (ESC), and a power steering, to wiper control, a security monitoring system, and the like. The development cost for the latter is said to be 25% or 40% of the total cost, and accounts for 70% in a hybrid car.
Multiple ECUs are arranged to provide electronic control. The ECUs are connected to each other via an in-vehicle network such as a controller area network (CAN). The engine, the transmission, and the like, which are to be controlled, are wire-connected directly to the respective ECUs.
The ECU is a small computer, and is operated according to an interrupt from a sensor input or the like. Meanwhile, the engine and the like continuously perform mechanical operations. In other words, a computer digital system and a mechanical physical system perform cooperative operations in parallel in a single system as an automobile. Naturally, software supporting those operations has become more and more complicated. Therefore, it is desired to achieve a mechanism not only for verifying the operation of a single ECU but also for verifying the operations of multiple ECUs at the same time.
Meanwhile, actuators driven by output signals from respective ECUs include an electromagnetic solenoid, a motor, etc. The solenoid is used, for example, for an injector of the engine, shift control of the transmission, brake valve control, door lock, and the like.
As a conventional technique for testing such devices, there is HILS (Hardware In the Loop Simulation). Particularly, an environment for testing all the ECUs in the automobile is called full-vehicle HILS. In the full-vehicle HILS, a test is conducted in a laboratory according to a predetermined scenario by connecting a real ECU to a dedicated hardware device emulating an engine, a transmission mechanism, or the like. The output from the ECU is input to a monitoring computer, and further displayed on a display to allow a person in charge of the test to check if there is any abnormal action while viewing the display.
However, in HILS, the dedicated hardware device is used and the device and the real ECU have to be physically wired. Thus, HILS involves a lot of preparation. Further, when a test is conducted by replacing one ECU with another, the device and the ECU have to be physically reconnected, requiring even more work. Since the test uses the real ECU, it takes actual time to conduct the test. Therefore, it takes an immense amount of time to test many scenarios. In addition, the hardware device for emulation of HILS is generally very expensive.
Therefore, there has recently been a technique using software without using such an expensive emulation hardware device. This technique is called SILS (Software In the Loop Simulation), in which all components to be mounted in the ECU, such as a microcomputer, an I/O circuit, and a control scenario, are configured by using a software simulator. This enables the test to be conducted without the hardware of the ECU.
A simulation system for automobiles includes a continuous system simulator and a discrete system (discrete event) simulator. An example of the continuous system simulator is a simulator for simulating a mechanical part of the engine. An example of the discrete event simulator is a simulator for an ECU operated with pulse timing of the engine rotation to control the timing of fuel injection or ignition.
For simulation of a 4WD, there is a simulator for repeatedly calculating the behavior of the car from the torque distribution to each wheel as an example of the continuous system simulator, and there is a simulator operated with a periodic pulse signal output at every interval of 10 milliseconds to simulate an ECU to determine the torque distribution to each wheel from a sensor input such as the yaw rate of the car as an example of the discrete event simulator.
The discrete event simulator reads and writes data through an I/O port other than input of pulse signals asynchronously with respect to the time slices of the continuous system simulator. Typically, it reads data from a sensor and updates it.
An ECU emulator as a typical discrete event simulator consists of CPU emulators and peripherals that interface the CPU emulators with the continuous system simulator.
The simulation of peripherals is a particular problem in such a simulator. Since the peripherals are of many kinds and their operation timings vary from peripheral to peripheral, it is difficult to configure the simulation system to operate correctly.
One solution is to run a peripheral emulator step by step while faithfully following hardware descriptions provided by an ECU vendor.
The TLM 2.0 user manual (June 2008) gives a description about “Loosely-timed coding style and temporal decoupling” at Chapter 3.3.2.
Japanese Patent Application Publication No. 2001-101156 discloses a system for automatically estimating an optimum simulation parameter. The system includes a parameter variation setting dialog window used for setting a start value, a variable step width, and an end value to create a parameter variation table in order to enable an objective judgment of the consistency between raw data and simulation data, and a data comparison module for evaluating the degree of similarity between the result of simulated calculation and comparative data, in which the simulated calculation is performed on all conditions in the parameter variation table to evaluate the degree of similarity between the calculation result and the comparative data so as to estimate the optimum simulation parameter.
Japanese Patent Application Publication No. 2002-318990 discloses a simulation system, in which processing is performed in a known state up to the jth step, and a predictor and a corrector are calculated at the j+1th step to determine whether an estimate of error is smaller than an error tolerance. When the result of determination is “Yes,” the next step width or solution is calculated and processing is advanced by one step. When the result of determination is “No,” the step width is reduced or processing is returned by one step.
With the above conventional techniques the simulation system is operated at more relaxed timing than previously and the operation conditions are changed as required. However, adjustment of operation timing among multiple functional blocks, such as peripherals, different in operating condition is neither disclosed nor suggested.